Subject:      Guide to Win95 support for DOS app's
To: GUISPEAK@LISTSERV.NODAK.EDU
Content-Type: text

I found two more excerpts about DOS sessions under Windows 95
that I think are worth sharing.  One is from the Windows 95
Reviewer's Guide, and the other is from the Windows 95
Resource Kit.  Together, they explain the concepts and variables
regarding support of DOS applications by Windows 95.  Since
Windows screen readers are still catching up to their DOS
counterparts, the information is helpful for configuring a
computer system to continue efficient DOS applications while
incorporating innovative GUI ones.

----------

>From the Windows 95 Reviewer's Guide:


1


CHAPTER6


Support for Running

MS-DOS


Support for MS-DOS based applications, device drivers, and TSRs
is maintained in Windows 95. In fact, Windows 95 offers better
compatibility for running MS-DOS based applications than Windows
3.1 does, including applications that are hardware- intensive,
such as games.

Like Windows 3.1, Windows 95 allows users to launch an MS-DOS
command prompt as an MS-DOS VM.  The functionality supported in
an MS-DOS VM is the same as that available under the latest
version of MS-DOS, allowing users to run the same intrinsic
commands and utilities.

95 delivers great support for running MS- based applications and
enables even
applications that would not run under Windows 3.1 to run
properly. This support allows MS-DOS based applications to
coexist peacefully with the rest of the Windows 95 environment.


Summary of Improvements over Windows 3.1

Improvements made to the system provide the following benefits
for running MS-DOS-based applications in the Windows 95
environment:

Zero conventional memory footprint for protected-mode components

Improved compatibility for running MS-DOS-based applications

Improved robustness for MS-DOS-based applications


Better support for running MS-DOS-based games, including in a
window

Support for running existing MS-DOS-based applications without
exiting Windows 95 or running MS-DOS externally

Consolidated attributes for customizing the properties of
MS-DOS-based applications

The availability of the Toolbar when running an MS-DOS-based
application in a window, providing quick access to features and
the functionality for manipulating the window environment

A user-scaleable MS-DOS window through the use of TrueType fonts

The ability to gracefully end an MS-DOS-based application without
exiting the application

The ability to specify local VM environment settings on a
per-application basis through the use of a separate batch file

Support for new MS-DOS commands, providing tighter integration
between the MS-DOS command line and the Windows environment


Zero Conventional Memory

Footprint Components

Windows 95 helps make the maximum amount of conventional memory
available for running existing MS-DOS-based applications. Some
MS-DOS-based applications did not run under Windows 3.1 because
by the time MS-DOS-based device drivers, MS-DOS- based TSRs,
MS-DOS-based networking components, and Windows 3.1 were loaded,
not enough conventional memory was available. Windows 95 replaces
many of the 16-bit real-mode components with 32-bit
protected-mode counterparts to provide the same functionality
while improving overall system performance and using no
conventional memory.

32-bit virtual device drivers are provided to replace their
16-bit real-mode counterparts for

Chapter 6 Support for Running MS-DOS 3


functions such as those listed in the table on the facing page.


The memory savings that results from using 32-bit protected-mode
components can be quite dramatic.  For example, if a PC were
configured with the NetWare NETX client software and used a SCSI
CD- ROM drive, SMARTDrive, the MS-DOS mouse driver, and
DriveSpace disk compression, the conventional memory savings that
would result from using Windows 95 would be over 262 KB!


Functions Carried Out by 32-Bit Device Drivers
in Windows

Convention
Description
Saved

Microsoft NetworkNET.EXE95 KB
client software(full)3 KB
PROTMAN35 KB
NETBEUI8 KB
EXP16.DOS (MAC)

Novell NetWareLSL5 KB
client softwareEXP16ODI9 KB
(MLID)16 KB
IPXODI.COM30 KB
NETBIOS.EXE48 KB
NETX.EXE47 KB
VLM.EXE

MS-DOS extendedSHARE.EXE17 KB
file sharing and
locking support

Adaptec SCSI driverASPI4DOS.SY5 KB
S

Adaptec CD-ROMASPICD.SYS11 KB
driver

Microsoft CD-ROMMSCDEX.EXE39 KB
Extensions

SmartDrive diskSMARTDRV.EX28 KB
caching softwareE

Microsoft MouseMOUSE.COM17 KB
driver

MicrosoftDRVSPACE.BI37 KB
DriveSpace diskN
compression driver
Chapter 6 Support for Running MS-DOS 5


Try It!

Test Conventional Memory Savings

1.
similar to one that now runs Windows 3.1. For example, use PCs
with SCSI drivers, network drivers, and system support files,
such as SMARTDRV, MSCDEX, or SHARE.

2.
loaded on both machines, type mem /c at a command prompt command
under Windows 3.1 and under Windows 95. Notice the memory savings
under Windows 95 for the same configuration.


Compatibility Improvements

For a number of reasons, some MS-DOS-based applications wouldn't
run properly under Windows
3.1.For example, some MS-DOS-based applications required that
lots of free conventional memory be available and thus were
prevented from running in an MS-DOS VM by large real-mode
components, such as network drivers or device drivers. Other MS-
DOS-based applications wouldn't run under Windows 3.1 because
they required direct access to the computer hardware and
conflicted with Windows internal drivers or other device drivers.

The MS-DOS support goal of Windows 95 is to be able to run the
``clean'' MS-DOS-based applications that ran under Windows 3.1
and the ``bad'' MS-DOS-based applications that tried to take over
the hardware or required machine resources unavailable under
Windows 3.1.

Many MS-DOS-based games assume that they are the only application
running on the system and access and manipulate the underlying
hardware directly, thus preventing them from being run in an
MS-DOS VM under Windows 3.1. Games are the most notorious class
of MS-DOS-based applications that don't get along well with
Windows 3.1. Some of these applications write to video memory
directly, manipulate hardware support resources such as clock
timers, and take over hardware resources such as sound cards.


A number of strategies have been used to provide better support
for running MS-DOS-based applications that interact with the
hardware, including better virtualization of computer resources
such as timers and sound devices. In addition, the use of 32-bit
protected-mode device drivers benefits MS-DOS-based applications
by providing more free conventional memory than was available
under Windows 3.1, so that memory- intensive applications run
properly.

Different MS-DOS-based applications require varying levels of
support from both the computer hardware and from the operating
system. For example, some MS-DOS-based games require close to 100
percent use of the CPU to perform properly, and other
MS-DOS-based applications modify interrupt addresses and other
low-level hardware settings. Windows 95 provides several
different levels of support for running MS-DOS-based
applications. These levels of support take into account that
different applications interact with the hardware in different
ways, and that some behave well, whereas others expect exclusive
access to the PC system and hardware. By default, MS-DOS-based
applications are preemptively multitasked with other tasks
running on the system and can run either full-screen or in a
window.  (CPU-intensive MS-DOS-based applications may not perform
well in a window but can be run in full- screen mode to get the
best response level.)


APPS.INF
Windows 95 provides an INF file that contains program settings
for many of the popular MS-DOS- based applications.  These
program settings are based on results from testing of Windows 95
and specify and special configuration-related settings that are
necessary to allow the application to run under Windows 95.

The APPS.INF file is processed when the user attempts to execute
an MS-DOS-based application from the Windows 95 user interface.
If a program information file (PIF) doesn't exist for the MS-
DOS-based application, the APPS.INF file will be examined by the
system for information about the specified MS-DOS-based
application.  If the application is listed in the APPS.INF file,
the system will read the contents and create a PIF

Chapter 6 Support for Running MS-DOS 7


that will be used when the application is executed.


MS-DOS Mode
To provide support for the most intrusive set of MS-DOS-based
applications that work only under MS- DOS and require 100 percent
access to the system components and system resources, Windows 95
provides a mechanism that is the equivalent of running an
MS-DOS-based application in real-mode MS-DOS. This mechanism,
called MS-DOS mode, provides an ``escape hatch'' for applications
that run only under MS-DOS. In this mode, Windows 95 removes
itself from memory (except for a small stub) and provides the
MS-DOS-based application with full access to all the resources in
the computer. Relatively few MS-DOS-based applications need to
run in single MS-DOS application mode because of the improved
compatibility support provided by Windows 95.

To run an MS-DOS-based application in this mode, the user sets
the MS-DOS Mode property on the Advanced Program Settings dialog
(from the Advanced button on the Program tab) of the MS-DOS
property sheet for the application. To create a unique
environment tailored to an application's needs and system
requirements, the user can also specify a CONFIG.SYS or
AUTOEXEC.BAT file to run for the application. When the user runs
an MS-DOS- based application in this mode, Windows 95 asks
whether running tasks can be ended. With the user's approval,
Windows 95 ends all running tasks, configures the machine to use
the CONFIG.SYS and AUTOEXEC.BAT files for the MS-DOS mode
session, restarts the computer, loads a real- mode copy of
MS-DOS, and launches the specified application. This process is
like exiting Windows 3.1 and then running the specified
MS-DOS-based application under MS-DOS. When the user exits the
MS-DOS-based application, Windows 95 restarts and returns the
user to the Windows 95 shell. This solution is much more elegant
than requiring users to dual-boot between different operating
systems in order to run desired applications.

Some entries in the APPS.INF file contain setting information
that instruct Windows 95 to run an MS- DOS-based application in
MS-DOS mode.  For these applications, they will only run in
MS-DOS mode


due to problems they have running in the protect- mode
environment of Windows 95, or due to assumptions they make about
the environment (e.g., addressing of extended memory for loading
their information) that prevent them from running under Windows
95.

Try It!

Run an MS-DOS

1.
know does not run under Windows 3.1, and run it under Windows 95.

2.
know runs under Windows 3.1 full-screen but not in a window, and
run it under Windows 95 in a window.


Support for Graphic-Intensive

MS-DOS

Windows 95 improves the support for running graphic-intensive
MS-DOS-based applications in the Windows environment.
MS-DOS-based applications that use VGA graphic video modes can
now be run in a window; they no long have to be run in full-
screen mode as with Windows 3.1. Users can still choose to run
graphic-intensive MS-DOS-based applications in full-screen mode
for the best level of performance.


Memory Protection
To support a higher level of memory protection for running
MS-DOS-based applications, Windows 95 includes on the Program
property sheet a global memory protection attribute that allows
the MS-DOS system area to be protected from errant MS-DOS- based
applications. When the global memory protection attribute is set,
the MS-DOS system area sections are read-protected so that
applications can't write to this memory area and corrupt MS-DOS
support and MS-DOS-based device drivers. In addition to system
area protection, enhanced parameter validation is performed for

Chapter 6 Support for Running MS-DOS 9


file I/O requests issued through the MS-DOS Int 21h function,
providing a higher degree of safety.

This option is not enabled by default for all MS- DOS-based
applications because of the additional overhead associated with
providing improved parameter and memory address checking. Users
can set this flag if they constantly have difficulty running a
specific MS-DOS-based application.


Better Defaults for Running

MS-DOS

By default, Windows 3.1 ran MS-DOS-based applications full screen
and disabled the ability of MS-DOS-based applications to run in
the background. To change this default behavior for a specific
MS-DOS-based application, users had to use the PIF Editor
(PIFEDIT) application to modify or create a program information
file (PIF) for the application.

By default, Windows 95 runs MS-DOS-based applications in a window
and enables the background-execution setting, allowing the
application to continue to run when it is not the active
application. This change in default behavior provides better
integration of running MS-DOS-based applications and
Windows-based applications without requiring users to change or
customize the state of the system.


Consolidated Customization of

MS-DOS

Each MS-DOS-based application has different characteristics and
mechanisms for using machine resources such as memory, video, and
keyboard access. Both Windows 95 and Windows 3.1 understand how
to run Windows-based applications because requests for system
services are handled through the use of the Windows API. However,
MS-DOS-based applications include only minimal information about
their requirements in the format of their .EXE headers. To
provide additional information about their requirements to the
Windows


environment, PIFs are used to specify the necessary configuration
settings.

Under Windows 3.1, the PIF Editor application, shown in Figure
39, was used to create or change properties associated with
running MS-DOS-based applications. Problems associated with the
PIF Editor and the PIF creation process included difficulty in
accessing the PIF Editor and PIF settings, the lack of
association for new users between PIF properties and the
MS-DOS-based application, the lack of a single location for
storing PIF files (other than placing them all in the Windows
directory), and less-than-intelligent defaults for running
MS-DOS-based applications.


Figure 39. The PIF Editor in Windows 3.1

Windows 95 enhances the ability to define properties for running
MS-DOS-based applications by consolidating PIF files into a
single location (the PIF directory where Windows 95 is
installed), providing easy access to property information for an
application (right-clicking the application's icon or window),
and providing better organization of properties (through the use
of a tabbed property sheet, shown in Figure 40). By means of
these improvements, Windows 95 provides greater flexibility and
control for running MS-DOS-based applications.

Chapter 6 Support for Running MS-DOS 11


Figure 40. The property sheet for configuring an MS-DOS

Try It!

View the Property Sheet for an MS-DOS Application

1.
application, and choose Properties.

2.
based application, and choose Properties.


Toolbars in MS-DOS Windows

In addition to providing compatibility enhancements to better
support the running of MS- DOS-based applications, Windows 95
makes using MS- DOS-based applications in the Windows environment
even easier than Windows 3.1. Many Windows-based applications
provide one or more toolbars for quickly accessing common
features and functionality, Windows 95 extends this simple but
powerful feature to provide easy access to the functionality
associated with an MS-DOS-based application, as shown in Figure
41.


Figure 41. A toolbar in a windowed MS-DOS box

Optionally, users can enable the display of a toolbar in the
window of a running MS-DOS-based application to provide the user
with quick access to the following functionality:

Simpler access to cut, copy, and paste operations for integrating
text or graphic MS- DOS-based applications with Windows-based
applications

Easy switching from windowed to full-screen mode

Quick access to property sheets associated with the MS-DOS-based
application

Access to MS-DOS VM tasking properties, such as exclusive or
foreground processing attributes

Easier access to font options for displaying text in a windowed
MS-DOS VM


Scaleable MS-DOS Windows
Windows 95 supports the use of a TrueType font in a windowed
MS-DOS VM, which allows users to scale the MS-DOS window to any
size. When the font size is set to Auto, the contents of the
MS-DOS window are sized automatically to display the entire
window within the user-specified area. Figure 42 shows the size
of the MS-DOS command prompt window being made smaller.

Chapter 6 Support for Running MS-DOS 13


Figure 42. Because of TrueType font support, the contents of this
MS-DOS window will be scaled to fit the smaller size of the
window so that they are still displayed in their entirety.

Try It!

Scale an MS-DOS Window

1.
the property sheet, and check that the font size is set to Auto.

2.
corner of the window, change the size of the window, and notice
how the window's contents are rescaled. (This functionality is
more noticeable when performed at higher resolutions.)


Ending MS-DOS

Applications Gracefully

Windows 95 provides support for gracefully closing an MS-DOS VM
through a property sheet setting that is available on an
application-by-application basis. When this setting is enabled,
users can close the MS-DOS-based application just as they would a
Windows-based application--- Close Window button.

In addition to gracefully ending an MS-DOS-based application,
robustness improvements made to the Windows 95 system ensure that
system clean-up is completed properly and that all allocated
resources are freed. As a result, memory used by


an MS-DOS-based application running under Windows 95 is
deallocated properly and made available for use by other
applications (unlike under Windows 3.1, which didn't properly
free DPMI memory).


Local Virtual Machine Environment Settings

When Windows 3.1 started, it used the MS-DOS environment
specified before it started as the default state for each
subsequently created MS-DOS VM. Any TSRs or other memory resident
software that was loaded before Windows started was replicated
across all MS-DOS VMs, whether the VM needed it or not. With
Windows 3.1, users could not run a batch file to set the VM
environment before starting a given MS-DOS-based application.
(Actually, users could run a batch file under Windows 3.1, but
when the batch file finished processing the command statements,
the MS-DOS VM was closed.)

Under Windows 95, a batch file can be optionally specified for a
given MS-DOS-based application, allowing customization of the VM
on a local basis before running the MS-DOS-based application. The
batch file is specified on the Program tab of the MS-DOS-based
application's property sheet, as shown in Figure 43. Using a
batch file allows MS- DOS environment variables to be set or
customized for individual MS-DOS-based applications and for TSRs
to be loaded in the local VM only. This mechanism is like having
different AUTOEXEC.BAT files for different MS-DOS-based
applications.

Chapter 6 Support for Running MS-DOS 15


Figure 43. Specifying a batch file on the Program tab of the
MS-DOS


Support for Accessing Network Resources

with UNC Pathnames

Windows 95 makes accessing network resources from the MS-DOS
command prompt easier by supporting the use of universal naming
conventions (UNC). UNC provides a standard naming scheme for
referencing network servers and shared directories. It uses the
following syntax:

\\servername\sharename[\pathname]

The Windows 95 shell allows users to browse and connect to
network servers without mapping a drive letter to the network
resource. Windows 95 supports the same functionality at an MS-DOS
command prompt and allows the user to do the following:

View the contents of shared directories on network servers from
both Microsoft Network servers and Novell NetWare servers by
typing dir \\servername\

Copy files from the contents of shared directories on network
servers from
both Microsoft Network servers and Novell NetWare servers by
typing


copy \\
destination

Run applications from shared directories on network servers for
both Microsoft Network servers and Novell NetWare servers by
typing \\


New MS-DOS Prompt Commands

The MS-DOS command processor and utilities have been enhanced to
provide better integration between MS-DOS functionality and the
Windows environment. Commands that manipulate files have been
extended to support long filenames, and some new commands have
been added to Windows 95 to provide access to new capabilities
supported by the system.

For example, the start
following syntax:

start <

allows users to start an MS-DOS or Windows-based application from
the command prompt in one of the following ways:

Start an application by specifying the name of a document to
open, and Windows 95 launches the application associated with the
given file type. For example, typing start myfile.xls starts the
application associated with the specified file, if there is a
valid association.

Start an MS-DOS-based application in a different MS-DOS VM
instead of the current one.

Start a Windows-based application from an MS- DOS command prompt.
Typing the name of a Windows-based application is essentially the
same as typing start <application>.

Try It!

Launch an Application from the MS-DOS Command Prompt

1.
Chapter 6 Support for Running MS-DOS 17


2.
application in another VM.

3.
Windows-based application in minimized form.


Support for Long Filenames

Many MS-DOS intrinsic commands and utilities have been extended
to support the use of long filenames. For example, the following
commands are among those that have been extended to support long
filenames:

The dir
filenames in the directory structure, along with the
corresponding 8.3 filename. Also, the dir
users can display additional file details by typing dir /v.

The copy
mixing of long and short filenames in copy operations. For
example, typing copy myfile.txt ``this is my file''
long filename.
19

----------
 From the Windows 95 Resource Kit:


Application Support
  Configuring MS-DOS-Based Applications
Windows 95 configures conventional memory in the same way as
earlier versions of MS-DOS, allowing MS-DOS-based applications to
run smoothly in Windows 95. For more information about how
Windows 95 makes system memory available to MS-DOS-based
applications, see Performance Tuning.


Application Support
  Configuring MS-DOS-Based Applications
    Changing MS-DOS-Based Application Properties (PIF Files)
You can set unique properties for individual MS-DOS-based
applications. You may want to do this to customize the way an
application runs or if the default properties that Windows 95
uses do not work correctly.
An application's settings are recorded in its application
information file (PIF). Windows 95 has no separate PIF Editor. To
configure an application, right-click the application's
executable file, and then click Properties. Any settings you
change in the Properties dialog box are recorded in the PIF file.
When you replace Windows 3.1 with Windows 95, PIFs are upgraded
to the Windows 95 format. All existing settings should be
preserved, but you may want to verify that they have been.
Windows 95 first searches for a PIF in the directory that
contains the executable file you are starting. If Windows 95
cannot find a PIF there, it searches the Windows PIF directory.
If there is no PIF in the Windows PIF directory, Windows 95
searches the path specified in the AUTOEXEC.BAT file. If no PIF
is found, Windows 95 searches the APPS.INF file for a match.
If Windows 95 does not find an entry for an application in the
APPS.INF file, it uses default settings for the application. If
you replace Windows 3.1 with Windows 95, a _DEFAULT.PIF file
remains in the directory. In this case, Windows 95 uses
information in the _DEFAULT.PIF file to create a PIF for the
application.
If you do not have a _DEFAULT.PIF file and want to create one,
you can do so by copying the DOSPRMPT.PIF to _DEFAULT.PIF.
Regardless of how the settings for an application are initially
established, you can change them by right-clicking the
application's executable file, and then clicking Properties. For
more information, see the section Understanding the APPS.INF
File.

Note  You can run a batch file using that batch file's settings
by typing its name directly at the command prompt or in the Run
dialog box. To run a batch file using the settings of the command
prompt (COMMAND.COM), precede the name of the batch file with
command /c; for example, command /c myfile.bat.


Application Support
  Configuring MS-DOS-Based Applications
    Changing Memory Settings for MS-DOS-Based Applications
Windows 95 provides a flexible environment for running
MS-DOS-based applications, even those applications that must have
exclusive access to system resources. Almost all MS-DOS-based
applications should run under Windows 95. For MS-DOS-based
applications that need sole access to computer resources, Windows
95 offers MS-DOS Mode.
When an MS-DOS-based application starts in MS-DOS Mode, Windows
95 removes itself from memory (except for a small stub) and
provides the application with full access to all the computer's
resources. Before running an application in this mode, Windows 95
ends all running tasks, loads a real-mode copy of MS-DOS, and
uses customized versions of the CONFIG.SYS and AUTOEXEC.BAT files
to run the application. After you quit the MS-DOS-based
application, Windows 95 restarts and returns to the Windows 95
user interface.

Caution  Running an MS-DOS-based application in MS-DOS Mode does
not necessarily improve its performance, but it does allow you to
run it when it might not otherwise run in Windows 95.


 To configure an MS-DOS-based application to run in MS-DOS Mode
     1.   In My Computer, right-click the application's
executable file, and then click Properties.
     2.   In the application's properties, click the Program tab,
and then click Advanced.
     3.   In the Advanced dialog box, click MS-DOS Mode.
If an MS-DOS-based application, such as a game, performs badly
because of insufficient memory or a lack of appropriate drivers,
you can try the following:
7    Run the application in MS-DOS Mode.
7    Adjust the amount of memory available.
7    Create a custom startup configuration by modifying the
contents of the CONFIG.SYS and AUTOEXEC.BAT files, either at the
command prompt or in the application's properties.


 To adjust the amount of memory available to an MS-DOS-based
application
     1.   In My Computer, right-click the application's
executable file, and then click Properties.
     2.   In the Application's properties, click the Memory tab,
and then increase or decrease the amount of memory available to
the application. For more information about the types of memory,
see Setting Properties for MS-DOS-Based Applications.


 To create a custom startup configuration
     1.   In My Computer, right-click the application's
executable file, and then click Properties.
     2.   In the application's properties, click the Application
tab, and then click Advanced.
     3.   In the Advanced dialog box, click MS-DOS Mode, click
the option named Specify A New MS-DOS Configuration, and then
create a custom startup configuration.

Note  Windows 95 automatically provides expanded memory for
MS-DOS-based applications that require it to run. Windows cannot
provide this memory, however, if you include a statement in
CONFIG.SYS that loads EMM386.EXE with the noems parameter. When
you include EMM386.EXE in CONFIG.SYS, use the ram parameter or
use the x=mmmm-nnnn statement to allocate enough space in the
upper memory area for Windows 95 to create an EMS page frame. For
more information, see Command-Line Commands Summary.


Tip for Running MS-DOS-Based GamesIn most cases, MS-DOS-based
games run under Windows 95 with no special adjustments. Most
popular games are listed in the Windows 95 APPS.INF file. Games
that include a Windows 3.1 PIF file should also continue to
perform well. Certain PIF settings are now obsolete, however,
because Windows 95 manages them automatically. These settings
include foreground and background priorities, exclusive priority,
video memory usage, and video port monitoring.
If you run a game that uses graphics modes and Windows 95 fails
to run it in a full screen, press ALT+ENTER. To run the game in a
full screen every time you start it, right-click the game's
executable file, and then click Properties. Click the Screen tab,
and then click Full Screen. You can also use the Properties
dialog box to adjust other settings that improve performance. For
more information, see Setting Properties for MS-DOS-Based
Applications.


Application Support
  Configuring MS-DOS-Based Applications
    Setting Properties for MS-DOS-Based Applications
In Windows 95, the properties sheets replace PIF Editor, which
was used in earlier versions of Windows to optimize settings for
MS-DOS-based applications.

 To view or modify the properties settings for an MS-DOS-based
program
     1.   Right-click the icon for the program, and then click
Properties. (If the program's icon is not on the Windows 95
desktop, use Windows Explorer to find the program, then
right-click the icon in Windows Explorer.) This displays the
properties sheets for the program.
     2.   Click the tab you want to use and change the options as
appropriate. (See the following section for information about all
of these options.)
     3.   Do the same for all other options and tabs, and then
click OK.
MS-DOS-based programs have six properties sheets - General,
Program, Font, Memory, Screen, and Misc.
Use the General properties to see information about the type,
size, and location of the MS-DOS-based application. From this
properties sheet, you can turn on and off the Read Only, Archive,
Hidden, and System attributes, which have the same meaning as
they do in MS-DOS.

Caution  Do not change file attributes unless you are absolutely
sure of what you are doing.

General properties
for an MS-DOS-based application


Use the Program properties to identify details about how the
program will be run.
Program properties
for an MS-DOS-based application



Option    Comments
(Filename)     Include the filename for the application.
Command Line   Type the full command line, including the correct
drive, path, and options, to run this application.
Working   Specify the working directory.
Batch File     Type the name of a batch file you want to run
before the program starts.
Shortcut Key   Specify the key combination (if any) that you want
to use to quickly switch to this application.
Run  Choose whether to run the program in a normal-sized window,
a maximized window, or a minimized window.
Close on Exit  Check this box if you want the window to close
after the
MS-DOS-based program has ended.
Use the Advanced command button to specify information about the
mode in which your program will run.
Advanced properties
for an MS-DOS-based application



Option    Comments
Prevent MS-DOS-based Programs From Detecting Windows   Check this
box to hide Windows 95 from MS-DOS-based applications for those
applications that cannot run or that perform poorly if they
detect the presence of Windows 95.
Suggest MS-DOS Mode As Necessary   Check this box to allow
Windows 95 to detect whether MS-DOS-based applications run best
in MS-DOS Mode. If it detects such an application, Windows 95
runs a wizard to set up a custom command to run the application.
MS-DOS Mode    Check this box to run this program in exclusive
MS-DOS Mode. No other processes are allowed to run simultaneously
if you use this option.
Warn Before Entering MS-DOS Mode   Check this box to enable the
automatic warning presented when Windows 95 is about to run an
application that requires MS-DOS Mode and must shut down all
other applications. If this option is checked, Windows 95 will
warn the user before beginning the shutdown process.
Specify A New MS-DOS Configuration Check this box to edit the
CONFIG.SYS and AUTOEXEC.BAT files in the corresponding text boxes
or by clicking the Configuration button.
CONFIG.SYS For MS-DOS Mode    Type any lines you want to add to
CONFIG.SYS to allow this application to run properly. This
version of CONFIG.SYS is used only for the MS-DOS Mode session in
which this application runs.
AUTOEXEC.BAT For MS-DOS Mode  Type any lines you want to add to
AUTOEXEC.BAT for this application. This version of AUTOEXEC.BAT
is used only for the MS-DOS Mode session in which this
application runs.
As shown in the preceding table, you can set the path for a
specific MS-DOS-based application that runs in MS-DOS Mode in the
AUTOEXEC.BAT box. For MS-DOS-based applications that don't run in
MS-DOS Mode, you can only set a working directory. You can set a
global path for all MS-DOS-based applications by adding a path
statement in AUTOEXEC.BAT. You can also write a batch file that
sets a path for an MS-DOS-based application; for example:
path=%path%;c:\utils;c:\norton

After you write the batch file, create a shortcut to your
MS-DOS-based application, and specify the batch file's path and
name in the Batch File field of the Program properties.
>From the Font properties, you can specify the font size and type
to be used when the MS-DOS-based program runs. From Font
properties, you can also preview how the program window and the
font will appear.
Font properties for an MS-DOS-based application


>From the Memory properties, you can define the following memory
allocation options:
7    Conventional memory, which consists of the first 640K of
memory available on your computer.
7    Expanded memory, which can be installed as an expanded
memory card or emulated by an expanded memory manager (EMM). EMM
software maps pages of expanded memory onto the system's upper
memory area.
7    Extended memory, which is essentially a seamless upward
extension of the original 1-MB address space available in the
memory of 80286 and 80386 computers. Extended memory always
starts at exactly 1024K, where the upper memory area ends.
7    MS-DOS protected-mode memory, which Windows 95 automatically
provides as expanded memory for MS-DOS-based applications that
require it to run. It cannot provide this memory, however, if you
include a statement in CONFIG.SYS that loads EMM386.EXE with the
noems parameter. Use the ram parameter when loading EMM386.EXE in
CONFIG.SYS, or use the x=mmmm-nnnn statement to allocate enough
space in the upper memory area for Windows 95 to create an EMS
page frame.
Using Upper Memory Blocks (UMBs) and High Memory Area (HMA) are
two ways to free conventional memory for use by MS-DOS-based
applications, and thus improve performance. In conventional
memory, UMBs are the unused part of upper memory from 640K to 1
MB, where information can be mapped to free memory below 640K.
HMA is the first 64K of extended memory, where drivers can be
loaded to free conventional memory.
Memory properties
for an MS-DOS-based application


>From the Screen properties, you can specify options for how the
application will be displayed.
Screen properties for an MS-DOS-based application



Option    Comments
Usage     Specify whether the application will run in a window
with an initial size you can specify, a full-screen window, or a
window with a size automatically determined by the graphic mode
it uses.
Windows   Choose whether to display a toolbar or to preserve the
previous Windows 95 window settings.
Performance    Choose Dynamic Memory Allocation to use the
Windows 95 video ROM-handling capabilities. Choose Fast ROM
Emulation to enable VxD emulation of selected video ROM services
and to speed up video operations, particularly text output.
>From the Misc properties, you can specify details about running
your program in the foreground and in the background. You can
specify whether your program must have exclusive access to the
system when it is in the foreground and whether running a screen
saver is allowed when the program is active. You can also specify
whether the program must be suspended when it is in the
background.
In addition, you can specify preferences for mouse, idle
sensitivity, Windows hot keys, and other options.
Miscellaneous properties for an
MS-DOS-based application


In Windows 95, the Properties dialog box replaces PIF Editor,
which was used in earlier versions of Windows to optimize the
settings for MS-DOS-based applications.
For information about changing the properties for executable
files, see online Help. For Help on the Properties dialog box of
an executable file, click the question mark button at the top of
the dialog box, and then click the item you want information
about.


 Application Support
  Configuring MS-DOS-Based Applications
    Setting Paths for MS-DOS-Based Applications
You can set the path for a specific MS-DOS-based application that
runs in MS-DOS Mode by carrying out the following procedure.

 To specify a path for MS-DOS-based applications that run in
MS-DOS Mode
     1.   Right-click the application's executable file, and then
click Properties.
     2.   Click the Application tab, and then click Advanced.
     3.   Make sure MS-DOS Mode is checked.
     4.   In the AUTOEXEC.BAT For MS-DOS Mode area, specify the
correct path.

Note  For MS-DOS-based applications that do not run in MS-DOS
Mode, you can set only a working directory.

You can set a global path for all MS-DOS-based applications by
adding a path statement to AUTOEXEC.BAT. You can also write a
batch file that sets a path for an MS-DOS-based application; for
example:
path=%path%;c:\utils;c:\norton

After you write the batch file, carry out the following procedure
to ensure that Windows runs it before starting your MS-DOS-based
application.

 To run a batch file before starting an MS-DOS-based application
     1.   In the application's properties, click Program.
     2.   In the Batch File area, specify the batch file's path
and name.
     3.   If you want the VM window in which the batch file is
running to close after the batch file has finished, make sure the
Close On Exit box is checked.
For more information about commands that can be used in batch
files, see Command-Line Commands Summary.


Application Support
  Configuring MS-DOS-Based Applications
    Understanding the APPS.INF File
APPS.INF contains a section named [PIF95] that acts as a master
list of settings for MS-DOS-based applications. Each line in this
section corresponds to a subsequent entry in APPS.INF that
contains information about running that specific application.
Each entry in the [PIF95] section uses the following syntax:
app file=%title%, icon file, icon num, set working, section,
other file, set pif
Entry     Meaning
app file  The filename, with extension, of the application's
executable file.
title     The name that appears in the application's title bar.
The string identifier must appear in the [Strings] section of the
INF file, set to the quoted name of the application.
icon file The file from which to extract the application's icon.
icon num  The number from the icon extraction table. The default
is 0.
set working    Allows the computer to automatically set the
working directory to the one that contains the executable (0, the
default), or prevents it from doing so (1).
section   The name of the corresponding section in APPS.INF that
contains details about this application.
other file     The key file within a directory for this
application, used when two app file entries are identically
named.
set pif   The value allowing (0, the default) or preventing (1)
creation of a PIF file for this application.
Each section following the [PIF95] section includes entries that
define any parameters, any required memory or other options, and
options that can be enabled or disabled. For example:
[WORD.EXE]
LowMem=384
Enable=cwe
Disable=win,bgd,asp

The Enabled= and Disabled= entries use the following
abbreviations. To separate multiple entries, use commas.
Entry     Meaning   Entry     Meaning
aen  ALT+ENTER eml  EMS memory locked
aes  ALT+ESC   ems  EMS memory
afp  Allow fast paste    emt  Emulate ROM
aps  ALT+PRINT SCREEN    exc  Exclusive mode
asp  ALT+SPACE gmp  Global memory protection
ata  ALT+TAB   hma  Use HMA
awc  Automatic window conversion   lml  Low memory locked
bgd  Background     mse  Mouse
cdr  CD-ROM    net  Network
ces  CTRL+ESC  psc  PRINT SCREEN
cwe  Close on exit  rvm  Retain video memory
dit  Detect idle time    rwp  Run Windows applications
dos  Real mode win  Run in a window
dsk  Disk lock xml  XMS memory locked

.

